Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUGFIX] - Merge query params from previous transition into active transition #13273

Merged
merged 2 commits into from
Jun 27, 2016

Conversation

raytiley
Copy link
Contributor

@raytiley raytiley commented Apr 7, 2016

This merges in queryParams from an active transition in such a way that prepareQueryParams won't duplicate them.

It also won't merge in the qp if it is already int he qp changed list, for example if it's already been set during route setup by a call to controller.set('qpProp', 'someValue').

Fixing these things with my current test jsbin also recreated another issue that has been biting people and that is that a call to transitionTo creates an aborted transition that calls didTransition with an empty set of handlerInfos. This would cause the updatePaths method to fail since it couldn't calculate the paths without the handler infos. We now bail early from updatePaths it is called with an empty array of handlerInfos.

I think this is fine because the aborted transition is followed by a successful transition that will update the paths appropriatly.

Still todo - TESTS

@@ -636,7 +636,17 @@ var EmberRouter = EmberObject.extend(Evented, {
// merge in any queryParams from the active transition which could include
// queryparams from the url on initial load.
if (this.router.activeTransition) {
assign(queryParams, this.router.activeTransition.queryParams);
var unchangedQPs = {};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this bit of code live in a separate method (_processActiveTransitionQueryParams or something)?

@rwjblue
Copy link
Member

rwjblue commented Apr 10, 2016

Thanks for working on this @raytiley, let me know if I can help...

@raytiley
Copy link
Contributor Author

Come to Maine and babysit for a few hours? I should be able to wrap this
up tonight.

On Sunday, April 10, 2016, Robert Jackson [email protected] wrote:

Thanks for working on this @raytiley https://github.com/raytiley, let
me know if I can help...


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#13273 (comment)

@rwjblue
Copy link
Member

rwjblue commented Apr 10, 2016

Come to Maine and babysit for a few hours? I should be able to wrap this up tonight.

Sounds fun! Might have to make a pit stop at the Bissell Brothers though....

@knownasilya
Copy link
Contributor

@raytiley I'm up to help any way I can, although visiting to babysit might be out of the question.

for (var j = 0, qpLen = qpMeta.qps.length; j < qpLen; ++j) {
var qp = qpMeta.qps[j];

var presentProp = qp.prop in queryParams && qp.prop ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please break this down and add more local vars to make this more readable

@raytiley
Copy link
Contributor Author

Hey Everyone... sorry. I've been really busy at work. I promise I will clean this up / get tests this week.

@igorT
Copy link
Member

igorT commented Apr 19, 2016

Nevermind, it was due to unrelated route recognizer bug.

I've been testing this PR in our app and it seems to fix certain query param issues that broke in 2.4.4 but introduces another bug where initial load of a page with a query 404s. Investigating

_normalizeQueryParams(leafRouteName, contexts, queryParams) {
var state = calculatePostTransitionState(this, leafRouteName, contexts);
var handlerInfos = state.handlerInfos;
var appCache = this._bucketCache;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unused

@raytiley
Copy link
Contributor Author

First steps... I rebased the code and fixed the jshint error. Tomorrow I'll write some tests based on some jsbin cases I used to write this code. Sorry for the delay.

@igorT
Copy link
Member

igorT commented Apr 21, 2016

@raytiley I added some tests here for things that worked in 2.4.3 and broke in 2.4.4 I think your branch fixed them as of yesterday.
53fcdbc

@@ -2490,6 +2490,43 @@ if (isEnabled('ember-routing-route-configured-query-params')) {
bootApplication();
});

QUnit.test('queryParams are updated when a controller property is set and the route is refreshed. Issue #13263 ', function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test looks good!

Seems to me that this test will fail with "Uncaught Error, Assertion Failed: You're not allowed to have more than one controller property map to the same query param key…" without the code to fix.

@lolmaus
Copy link
Contributor

lolmaus commented Apr 26, 2016

This issue needs to be properly tagged. At least with Query Params.

@lolmaus
Copy link
Contributor

lolmaus commented Apr 26, 2016

@Sinled has discovered a regression with an array query param.

Previously, you could have an array query param like this:

export default Ember.Controller.extend({
  queryParams: ['fields',],
  fields: ['field1', 'field2']
})

Ember would properly (and transparently!) serialize them into strings and then deserialze back.

After the regression, array query params are not deserialized and the Controller's array property gets rewritten with a string.

Me and @Sinled managed to narrow down the regression to this commit by @raytiley: master 2b42d56, lts-2-4 7460b68.

Please tell us whether:

  • this is a bug or works as designed;
  • this is a known or new issue;
  • it should be reported as a new GitHub issue ticket.

@rwjblue
Copy link
Member

rwjblue commented Apr 26, 2016

This issue needs to be properly tagged.

This comment is not helpful, please keep things constructive.

Please tell us whether:

  • this is a bug or works as designed;

Bug.

  • this is a known or new issue;

If you didn't find it via a GitHub search, it is a new issue. I personally do not recall an issue opened about 2.4.4 regarding array query params.

  • it should be reported as a new GitHub issue ticket.

If you didn't find it via a GitHub search, it is a new issue. Please test this PR to see if it fixes.

@@ -987,6 +1032,8 @@ function calculatePostTransitionState(emberRouter, leafRouteName, contexts) {

function updatePaths(router) {
let infos = router.router.currentHandlerInfos;
if (infos.length === 0) { return; }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm running into a similar problem but in my case infos isn't even an array. I did something like:

import { isArray } from 'ember-runtime/utils';
...
if (!isArray(infos) || infos.length === 0) { return; }

@homu
Copy link
Contributor

homu commented May 6, 2016

☔ The latest upstream changes (presumably b125ff5) made this pull request unmergeable. Please resolve the merge conflicts.

@knownasilya
Copy link
Contributor

I'm totally getting bit by the QPs not being deserialized properly (arrays) in the queryParamsDidChange hook. How's this PR going, and would it solve that?

@pixelhandler
Copy link
Contributor

@stefanpenner @chancancode question for you, do we need a "regression" label on this?

@pixelhandler
Copy link
Contributor

@raytiley thanks for putting this PR into play. This will help people that would like to adopt the LTS release. I spoke to a few people at our meetup Wed. And noticed those interested in LTS are running 2.4.3 instead of 2.4.5 due to #13258

@lolmaus
Copy link
Contributor

lolmaus commented Jun 5, 2016

Related: #13591

@Sinled
Copy link

Sinled commented Jun 14, 2016

2.4.6 fixed my problem with query params serialisation, but it still present in 2.6.0

@rwjblue
Copy link
Member

rwjblue commented Jun 14, 2016

Confirm. This PR is still needed.

@igorT - Were you going to pick this up?

@homu
Copy link
Contributor

homu commented Jun 15, 2016

☔ The latest upstream changes (presumably #13658) made this pull request unmergeable. Please resolve the merge conflicts.

raytiley and others added 2 commits June 27, 2016 09:20
This merges in queryParams from an active transition in such a way that
`prepareQueryParams` won't duplicate them.  It also won't merge in the
qp if it is already int he qp changed list, for example if it's already
been set during route setup by a call to `controller.set('qpProp',
'someValue')`.  Fixing these things with my current test jsbin also
recreated another issue that has been biting people and that is that a
call to `transitionTo` creates an aborted transition that calls
`didTransition` with an empty set of handlerInfos. This would cause the
`updatePaths` method to fail since it couldn't calculate the paths
without the handler infos. We now bail early from `updatePaths` it is
called with an empty array of handlerInfos.  I think this is fine
because the aborted transition is followed by a successful transition
that will update the paths appropriatly.

This gets the active queryParams and the provided using the same key
`controller:prop` so that the calls to `assign` override as expected.
This fixes issues where the QP doesn't update properly on refresh
because the merged value conflicts with the provided value.
@raytiley raytiley changed the title [WIP] - Fixing query params [BUGFIX] - Merge query params from previous transition into active transition Jun 27, 2016
@rwjblue rwjblue merged commit 7e62fb0 into emberjs:master Jun 27, 2016
@rwjblue rwjblue deleted the moar-qp-fixes branch June 27, 2016 13:58
@rwjblue
Copy link
Member

rwjblue commented Jun 27, 2016

🎉

@nathanhammond
Copy link
Member

Hey everybody who paid attention to this thread! We've a few open bugs likely triggered by this change. Anybody have time to dive in?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants